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Abstract 

Software architecture is receiving increasingly atten- 
tion as a critical design level for software systems. As 
software architecture design resources (in the form of 
architectural descriptions) are going to be accumulated, 
the development of techniques and tools to support ar- 
chitectural understanding, testing, reengineering, main- 
taining, and reusing will become an important issue. 
In this paper we introduce a new dependence analysis 
technique, named architectural dependence analysis to 
support software architecture development. In contrast 
to traditional dependence analysis, architectural depen- 
dence analysis is designed to operate on an architectural 
description of a software system, rather than the source 
code of a conventional program. Architectural depen- 
dence analysis provides knowledge of dependences for 
the high-level architecture of a software system, rather 
than the low-level implementation details of a conven- 
tional program. 

1 Introduction 

Software architecture is receiving increasingly atten- 
tion as a critical design level for software systems JL9| . 
The software architecture of a system defines its high- 
level structure, exposing its gross organization as a col- 
lection of interacting components. A well-defined archi- 
tecture allows an engineer to reason about system prop- 
erties at a high level of abstraction. The importance of 
software architecture for practicing software engineers 
is highlighted by the ubiquitous use of architectural de- 
scriptions in system documentation. 

Architectural description languages (ADLs) are for- 
mal languages that can be used to represent the archi- 
tecture of a software system. They focus on the high- 
level structure of the overall application rather than the 
implementation details of any specific source module. 
ADLs are intended to play an important role in the 
development of software by composing source modules 
rather than by composing individual statements writ- 
ten in conventional programming languages. Recently, 
a number of architectural description languages have 
been proposed such as ACME || , Rapide |llj , UniCon 
JD|, and Wright |2| to support formally representation 
and reasoning of software architectures. As software ar- 
chitecture design resources (in the form of architectural 
descriptions) are going to be accumulated, the develop- 
ment of techniques and tools to support understanding, 
testing, reengineering, maintaining, and reusing of soft- 
ware architectures will become an important issue. 



One promising way to support software architec- 
ture development is to use dependence analysis tech- 
nique. Program dependences are dependence relation- 
ships holding between program statements in a program 
that are determined by the control flows and data flows 
in the program. Usually, there are two types of program 
dependences in a conventional program, control depen- 
dences that represent the control conditions on which 
the execution of a statement or expression depends and 
data dependences that represent the flow of data be- 
tween statements or expressions. The task to determine 
a program's dependences is called program dependence 
analysis. We refer to this kind of dependence analysis 
as traditional dependence analysis to distinguish it from 
a new form dependence analysis introduced later. 

Traditional dependence analysis has been primarily 
studied in the context of conventional programming lan- 
guages. In such languages, it is typically performed 
using program dependence graphs ]4| [l0|, fLa, p2| . 
Traditional dependence analysis, thougnorigmaTTy pro- 
posed for complier optimization, has also many applica- 
tions in software engineering activities such as program 
slicing, understanding, debugging, testing, maintenance 
and complexity measurement jl], || [Hj [H], Ell ^| . 

Applying dependence analysis to software architec- 
tures promises benefit for software architecture devel- 
opment at least in two aspects. First, architectural un- 
derstanding and maintenance should benefit from de- 
pendence analysis. To understand a software architec- 
ture to make changes during maintenance, a maintainer 
must take into account the many complex dependence 
relationships between components and/or connectors in 
the architecture. This makes dependence analysis an 
essential step to architectural level understanding and 
maintenance. Second, architectural reuse should ben- 
efit from dependence analysis. While reuse of code is 
important, reuse of software designs and patterns may 
offer the greater potential for return on investment in 
order to make truly large gains in productivity and qual- 
ity. By analyzing dependences in an architectural de- 
scription of a software system, a system designer can 
extract reusable architectural descriptions from it, and 
reuse them into new system designs for which they are 
appropriate. 

While dependence analysis is useful in software ar- 
chitecture development, existing dependence analysis 
techniques for conventional programming languages can 
not be applied to architectural descriptions straightfor- 
wardly due to the following reasons. The traditional 
definition of dependences only concerned with programs 
written in conventional programming languages which 



primarily consist of variables and statements as their 
basic language elements, and dependences are usually 
defined as dependence relationships between statements 
or variables. However, in an architectural description 
language, the basic language elements are primarily 
components and connectors, but neither variables nor 
statements as in conventional programming languages. 
Moreover, in addition to definition/use binding rela- 
tionships, an architectural description language topi- 
cally support more broad and complex relationships 
between components and/or connectors such as pipes, 
event broadcast, and client-server protocol. As a result, 
new types of dependence relationships in an architec- 
tural description must be studied based on components 
and connectors. 

In this paper we introduce a new dependence analysis 
technique, named architectural dependence analysis to 
support software architecture development. In contrast 
to traditional dependence analysis, architectural depen- 
dence analysis is designed to operate on an architectural 
description of a software system, rather than the source 
code of a conventional program. Architectural depen- 
dence analysis provides knowledge of dependences for 
the high-level architecture of a software system, rather 
than the low-level implementation details of a conven- 
tional program. 

The purpose of development of architectural depen- 
dence analysis is quite different from the purpose for 
development of traditional dependence analysis. While 
traditional dependence analysis was designed originally 
for supporting compiler optimization of a conventional 
program, architectural dependence analysis was primar- 
ily designed for supporting architectural understand- 
ing and reuse of a large-scale software system. How- 
ever, just as traditional dependence analysis has many 
other applications in software engineering activities, we 
expect that architectural dependence analysis has also 
useful in other software architecture development activ- 
ities including architectural testing, reverse engineering, 
reengineering, and complexity measurement. 

The rest of the paper is organized as follows. Section 
briefly introduces the ACME: an architectural descrip- 
tion language. Section presents a dependence model 
for software architectures. Section ^ discusses some ap- 



plications 
in Section 



the model. Concluding remarks are given 



2 Architectural Descriptions in ACME 

We assume that readers are familiar with the basic 
concepts of architectural description languages, and in 
this paper, we use ACME architectural description lan- 
guage H as our target language to represent software 

architectures.. The selection of the ACME is based on its 
potentially wide use because "it is being developed as a 
joint effort of the software architecture research commu- 
nity to provide a common intermediate representation 
for a wide variety of architecture tools." S 

There are seven design elements in ACME that can 
be used to represent software architectures which in- 
clude components, connectors, systems, ports, roles, 
representations, and bindings. Among them, the most 
basic elements of architectural description are compo- 
nents, connectors, and systems. Readers can refer || for 
more details of the language description, and we briefly 
introduce these design elements here. 

Components are used to represent the primary com- 
putational elements and data stores of a system. Intu- 
itively, they correspond to the boxes in box-and-line de- 



scriptions of software architectures. Typical examples of 
components include clients, servers, filters, objects, and 
databases. Each component has its interface defined 
by a set of ports. A component may provide multiple 
interfaces by using different types of ports. Each port 
identifies a point of interaction between the component 
and its environment. A port can represent a simple in- 
terface such as procedure signature, or more complex 
interfaces, such as a collection of procedure calls that 
must be invoked in certain specified orders, or an event 
multi-cast interface point. 

Connectors are used to represent interactions be- 
tween components. Connectors mediate the communi- 
cation and coordination activities between components. 
Intuitively, they correspond to the lines in box-and-line 
descriptions, connectors may represent simple forms of 
interaction, such as pipes, procedure calls, event broad- 
casts, and also more complex interactions, such as a 
client-server protocol or a SQL link between a database 
and an application. Each connector has its interface de- 
fined by a set of roles. Each role of a connector defines a 
participant of the interaction represented by the connec- 
tor. Connectors may have two roles such as the caller 
and callee roles of an RPC connector, the reading and 
writing roles of a pipe, or the sender and receiver roles 
of a message passing connector, or more than two roles 
such as an even broadcast connector which might have 
a single event-announcer role and an arbitrary number 
of event- receiver roles. 

Systems represent configurations of components and 
connectors- 
Figure |5| (a) shows the ACME architectural descrip- 
tion of a simple London Ambulance Service dispatch 
system (LAS system) which is taken from [Q , and 
Figure W shows its architectural representation. The 
architectural representation contains five components 
which are connected by six connectors. For exam- 
ple, in the representation, the component call_entry 
and the component incident_mgr is connected by 
the connector call_inf o_channel. Each component 
is declared to have a set of ports, and each con- 
nector is declared to have a set of roles. For ex- 
ample, a component incident_mgr has four ports 

designed as map_request, incident_inf o_request, 
send_incident_inf o, and receive_call_msg, and a 
connector call_inf o_channel has two roles designed 
as from and to. The topology of the system is declared 
by a set of attachmentses. For example, an attachments 
incedent_inf o_path represents the connections from 
calls to incident-manager, incident updates to resource 
manager, and dispatch requests to dispatcher. 

In order to provide more information about archi- 
tectural descriptions, ACME also supports annotation 
of architectural structure with lists of properties. Each 
property has a name, an optional type, and a value, 
and each ACME architectural design entity can be 
annotated. For example, in Figurelq, the connector 
call_inf o_channell has a set of properties that state 
the connection type is massage passing channel and the 
message flow is from the role from to the role to. 

In order to focus on the key idea of architectural de- 
pendence analysis, we assume that an ACME architec- 
tural description contains these basic elements including 
component whose interface is defined by a set of ports, 
connector whose interface is defined by a set of roles 
and system whose topology is declared by a set of at- 
tachmentses each including a set of attachments. Rep- 
resentations and bindings will not be considered here, 
and we will consider them in our future work. 
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Figure 1: The architecture of the LAS system. 

3 A Dependence Model for Software 
Architectures 

In this section we first introduce three types of de- 
pendences in an architectural description, then present 
a dependence graph for architectural descriptions. 

3.1 Dependences in Architectural Descrip- 
tions 

Traditional dependence analysis has been primarily 
studied in the context of conventional programming lan- 
guages. In such languages, dependences are usually de- 
fined between statements or variables. However, in an 
architectural description language, the basic language 
elements are components and connectors, but neither 
statements nor variables. Moreover, in an architectural 
description languages, the interactions among compo- 
nents and/or connectors is through their interfaces that 
are usually defined to be a set of ports (for components) 
and a set of roles (for connectors). As a result, it is not 
enough to define dependences just between components 
and/or connectors in an architectural description. In 
this paper, we define dependences in an architectural 
description as dependence relationships between ports 
and/or roles of components and/or connectors. In the 
following, we present three types of dependences in an 
architectural description. 



Component-Connector Dependences 

The first type of dependence relationship in an archi- 
tectural description is called component- connector de- 
pendences which can be used to represent dependence 
relationships between a port of a component and a role 
of a connector in the description. Informally, if there 
is an information flow from a port of a component to 
a role of a connector, then there exists a component- 
connector dependence between them. For example, 
in Figure | (a), there is a component-connector de- 
pendence between the port receive_incident_inf o 
of the component resource_mgr and the role to of 
the connector incident_update_channel since there 
is a message flow from the role to to the port 
receive_incident_inf o. 



Connector-Component Dependences 

The second type of dependence relationship in an archi- 
tectural description is called connector- component de- 
pendences which can be used to represent dependence 
relationships between a role of a connector and a port 
of a component. Informally, if there is an information 
flow from a role of a connector to a port of a compo- 
nent, then there exists a connector-component depen- 
dence between them. For example, in Figure ^| (a), there 
is a connector-component dependence between the role 
from of the connector call_inf o_channel and the port 
send_call_msg of the component call_entry since 
there is a message flow from the port send_call_msg 
to the role from. 



Additional Dependences 

The third type of dependence relationships in an ar- 
chitectural description is called additional dependences 
which can be used to represent dependence relation- 
ships between two ports or roles within a compo- 
nent or connector. Informally, for a component or 
connector there are additional dependences from each 
port or role as input to other ports or roles as out- 
put. For example, in Figure || (a), there is an 
additional dependence between the roles client_end 
and server_end of the connector map_request_rpc2 
and also an additional dependence between the ports 
map_request and receive_incident_inf o of the com- 
ponent resource_msg. 

3.2 Software Architectural Dependence 
Graph 

It has been shown that a dependence graph repre- 
sentation such as the program dependence graph (PDG) 
|j, for programs written in conventional program- 
minglanguages, has many application in software engi- 
neering activities since it provides a powerful framework 
for control flow and date flow analysis. This motivates 
us to present a similar representation to explicitly repre- 
sent dependences in an architectural description. In this 
section, we present a dependence graph named software 
architectural dependence graph (SADG for short) for 
architectural descriptions to explicitly represent three 
types of dependences in an architectural description in- 
troduced above. The SADG of an architectural descrip- 
tion is an arc-classified digraph whose vertices represent 
the ports of components and the roles of the connectors 
in the description, and arcs represent three types of de- 
pendence relationships in the description. 
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Figure 2: The dependence graph of the architectural description in Figure ^. 



Figure ^| shows the SADG of the architectural 
description in Figure H In the fi gure, large 
squares represent components in the description, and 
small squares represent the ports of each compo- 
nent. Each port vertex has its name described 
by component_name. port-name. For example, pv8 
(resource_mgr . receive_incident_inf o) is a port 
vertex that repre- 

sents the port receive_incident_inf o of the compo- 
nent resource_mgr. Large circles represent connectors 
in the description, and small circles represent the roles 
of each connector. Each role vertex has its name de- 
scribed by connector •jname.rolejname. For example, rvl 
(incident_inf o_request_rpc . client_end) is a role 
vertex that represents the role client_end of the con- 
nector incident_inf o request. The complete descrip- 
tion of each vertex is shown in the bottom of the figure. 

Bold arcs represent component-connector depen- 
dence arcs that connect a port of a component to a role 
of a corresponding connector. Bold dashed arcs rep- 
resent connector-component dependence arcs that con- 
nect a role of a connector and a port of a corresponding 
component. Thin dashed arcs represent additional de- 
pendence arcs that connect two ports or roles within a 
component or connector. For example, (pv8,rvA) and 
(pv3,rv&) are component-connector dependence arcs. 
(rv5,pv9) and (ru9,pt>2) are connector-component de- 
pendence arcs. (rv2,rv\) and (rv6,rv5), and (pv2,pv5) 
and (pv7,pv8) are additional dependence arcs. 

Note that there are some efficient algorithms to com- 
pute program dependences and construct the depen- 



dence graph representations for programs written in 
conventional programming languages @ U|. These 
algorithms can easily be modified to compute depen- 
dences in an architectural description and construct the 
SADG representation as well. 

4 Applications 

As dependence graph representations for conven- 
tional programming languages have many applications 
in software engineering activities, the dependence model 
presented in this paper should have similar applications 
in practical development of software architectures. 

4.1 Architectural Slicing and Understand- 
ing 

Program slicing, originally introduced by Weiser pOj , 
is a decomposition technique which extracts programel- 
ements related to a particular computation. A program 
slice consists of those parts of a program that may di- 
rectly or indirectly affect the values computed at some 
program point of interest, referred to as a slicing cri- 
terion. We refer to this kind of slicing as traditional 
slicing. Traditional slicing has been widely studied in 
the context of traditional programming languages and 
has many applications in software engineering activities 
such as program understanding ||, debugging ]3J, test- 
ing 0, maintenance H and complexity measurement 

Having SADG as a representation of architectural de- 
scriptions, we can apply traditional slicing technique to 
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Figure 3: A slice over the ADDG of the architectural description in Figure ||. 



software architectures. We presented an entirely new 
form of slicing named architectural slicing, to slicing 
software architectures in order to support architectural 
understanding and reuse [p3| . Architectural slicing is 
designed to operate on the architectural description of 
a software system and can provide knowledge about the 
high-level architecture of a software system. 

Intuitively, an architectural slice may be viewed as a 
subset of the behavior of a, software architectural de- 
scription, similar to the original notion of the tradi- 
tional static slice. However, while a traditional slice 
intends to isolate the behavior of a specified set of pro- 
gram variables, an architectural slice intends to isolate 
the behavior of a specified set of a component's ports 
or a connector's roles. Given an architectural descrip- 
tion P = (C m ,C n , A m ) of a software system, our goal 
is to compute a slice S p — (C' m7 C' n , A' m ) that should be 
a "subset" of P that preserves partially the semantics 
of P. In |25j] , We use a dependence graph based ap- 
proach to compute an architectural slice, that is based 
on the SADG of the description. Our slicing algorithm 
contains two phases: 

Step 1: Computing a slice S g over the SADG of 
an architectural description, 

Figure || shows a slice over the ADDG in Figure |[ 



The slice was computed with respect to the slicing cri- 
terion (resource_mgr, V c ) such that V c — {pv7,pv8}. 

Step 2: Constructing an architectural description 
slice S p from S g . 

Figure || (b) shows a slice of the ACME description 
in Figure ^| (a) with re- 

spect to the slicing criterion (resource_mgr, E) such 
that E={incident_inf o_request, 

receive_incident_inf o} is a set of ports of compo- 
nent resource_mgr. The small rectangles represent the 
parts of description that have been removed, i.e., sliced 
away from the original description. The slice is obtained 
from a slice over the ADDG in Figure a according to the 
mapping process described above. Figure shows the 
architectural representation of the slice in Figure ^ (b) . 

In the following, we present a simple example to show 
how architectural slicing can be used to aid architectural 
understanding of a software system. 

Consider a simple London Ambulance Service dis- 
patch system (LAS system) whose ACME descrip- 
tion is shown in Figure || (a). This example 
is taken from Suppose a maintainer needs 

to modify two ports incident_inf o_request and 
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Figure 4: The architectural representation of the slice 
in Figure || (b) . 



receive_incident_inf o of the compo- 
nent resource_mgr in the architectural description in 
order to satisfy new design requirement, the first thing 
he/she has to do is to investigate which components 
and connectors interact with component resource_mgr 
through these two ports. A common way is to man- 
ually check the source code of the description to find 
such information. However, it is very time-consuming 
and error-prone even for a small size description be- 
cause there may be complex dependence relations be- 
tween components and/or connectors in the description. 
However, if the maintainer has an architectural sheer in 
hand, The work may probably be simplified and auto- 
mated without the disadvantages mentioned above. In 
such a scenario, he/she only needs to invoke the sheer, 
which takes as input a complete architectural descrip- 
tion of the system and the set of ports of the com- 
ponent resource_mgr, i.e., incident_inf o_request , 
receive_incident_inf o (this is an architectural slic- 
ing criterion). The sheer then computes an architec- 
tural slice with respect to the criterion and outputs it 
to the maintainer. Such a slice is a partial descrip- 
tion of the original one which includes those compo- 
nents and connectors that might affect the component 
resource_mgr through ports in the criterion. The other 
parts of the description that might not affect the compo- 
nent resource_mgr have been removed, i.e., sliced away 
from the original description. The maintainer can thus 
focus his/her attention only on the contents included in 
the slice to investigate the impact of modification. 

4.2 Architectural Reuse 

While reuse of code is important, in order to make 
truly large gains in productivity and quality, reuse of 
software designs and patterns may offer the greater po- 
tential for return on investment. Although there are 
many researches have been proposed for reuse of code, 
little reuse method has been proposed for architectural 
reuse. By slicing an architectural description of a soft- 



ware system, a system designer can extract reusable ar- 
chitectural descriptions from it, and reuse them into new 
system designs for which they are appropriate. 

5 Concluding Remarks 

Software architecture is receiving increasingly atten- 
tion as a critical design level for software systems. As 
software architecture design resources (in the form of ar- 
chitectural descriptions) are going to be accumulated, 
the development of techniques and tools to support 
architectural-level understanding, testing, reengineer- 
ing, maintaining, and reusing will become an impor- 
tant issue. In this paper we introduce a new depen- 
dence analysis technique, named architectural depen- 
dence analysis to support software architecture devel- 
opment. In contrast to traditional dependence anal- 
ysis, architectural dependence analysis is designed to 
operate on an architectural description of a software 
system, rather than the source code of a conventional 
program. Architectural dependence analysis provides 
knowledge of dependences for the high-level architecture 
of a software system, rather than the low-level imple- 
mentation details of a conventional program. In order 
to perform architectural dependence analysis, we also 
presented the software architectural dependence graph 
to explicitly represent various types of dependences in 
an architectural description of a software system. While 
our initial exploration used ACME as the architectural 
description language, the concept and approach of archi- 
tectural dependence analysis are language-independent. 
However, the implementation of an architectural depen- 
dence analysis tool may differ from one architecture de- 
scription language to another because each language has 
its own structure and syntax which must be handled 
carefully. 

In architectural description languages, in addition 
to provide both a conceptual framework and a con- 
crete syntax for characterizing software architectures, 
they also provide tools for parsing, displaying, compil- 
ing, analyzing, or simulating architectural descriptions 
written in their associated language. However, exist- 
ing language environments provide no tools to support 
architectural understanding, maintenance, testing, and 
reuse from an engineering viewpoint. We believe that 
a dependence analysis tool such as an architectural de- 
pendence analyzer introduced in this paper should be 
provided by any ADL as an essential means to support 
software architecture development activities. 

As future work, we would like to extend our approach 
presented in this paper to handle other constructs in 
ACME language such as templates and styles which were 
not considered here, and also to extend our approach 
to handle other architecture description languages such 
as UniCon and Wright. Moreover, to demonstrate the 
usefulness of our dependence analysis approach, we are 
implementing an architectural dependence analyzer for 
ACME architectural descriptions to support architec- 
tural understanding and reuse. The next step for us is 
to perform some experiments to evaluate the usefulness 
of architectural dependence analysis in practical devel- 
opment of software architectures. 
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/ / Instance based example - simple LAS architecture: // 
System LAS_CAD = { S\ 
II system components li 
call_entry = component { 

ports : ( send_call_msg } 

} 

incident_mgr = component { 

ports : ( map_request, incident_inf o_request , 

send_incident_inf o, receive_call_msg } 

} 

resource_mgr = component { 

ports : { map_request, incident_inf o_request , 

receive_incident_inf o, send_dispatch_request } 

} 

dispatcher = component { 

ports : { receive_dispatch_request } 

} 

ma p _ s e r v e r = c omponent { 

ports : { request_portl, request_port2 } 

} 

// system connectors // 
II message passing connectors 
call_info_channel = connector ( 
roles : { from, to } 

properties : { conn_type : string = message_pass_channel; 

msg_f low : f low_direction = from -> to; } 

} 

incident_update_channel = connector { 
roles : { from, to } 

properties : { conn_type : string = message_pass_channel; 

msg_f low : f low_direction = from -> to; } 

} 

dispatch_request_channel = connector ( 
roles : {from, to } 

properties : { conn_type : string = message_pass_channel; 

msg_f low : f low_direction = from -> to; } 

} 

// RPC connectors 

incident_inf o_request_rpc = connector { 
roles : { client_end, server_end } 
property : { conn_type : string = RPC; ) 

} 

map_request_rpcl = connector { 

roles : { client_end, server_end } 
property : { conn_type : string = RPC; ) 

} 

map_request_rpc2 = connector { 

roles : (client_end, server_end ) 
property : { conn_type : string = RPC; ) 

} 



Instance based example - simple LAS architecture: 
stem LAS_CAD = { 
system components 
call_entry = component { 

ports : { send_call_msg } 



> 



ident_mgr = component { 
ports : \ \ 



] incident_inf o_request , 



send_incident_inf o, receive_call_msg } 



resource_mgr = component { 
ports : { map_request. 



receive_incident_inf o[~ 



J ) 



system connectors 

// message passing connectors 

call_info_channel = connector { 



{ 



I 



properties : { conn_type : string = message_pass_channel; 

msg_f low : f low_direction = from -> to; ) 

I 

incident_update_channel = connector { 
roles : | from, to } 

properties : { conn_type : string = message_pass_channel; 

msg_f low : f low_direction = from -> to; ) 

} 



// RPC connectors 

incident_info_request_rpc = connector { 
roles : { client_end, server_end ) 
property : { conn_type : string = RPC; } 

1 



connect up the attachments 
incident_inf o_path = attachments : { 
// calls to incident_manager 

call_entry . send_call_msg to call_inf o_channel . to 



nnect up the attachment s 
cident_info_path = attachments : { 
// calls to incident_manager 

call_entry . send_call_msg to call_inf o_channel . to; 



// incident updates to resource manager 
incident_mgr . send_incident_inf o to 

incident_update_channel . from; 
resource_mgr . receive_incident_inf o to 

incident_update_channel . to; 



// incident updates to resource manager 
incident_mgr . send_incident_inf o to 

incident_update_channel . from; 
resource_mgr . receive_incident_inf o to 

incident_update_channel . to; 



// dispatch requests to dispatcher 
resource_mgr . send_dispatch_request to 

dispatch_request_channel .from; 
dispatcher . receive_dispatch_request to 

dispatch_request_channel .to; 



} 



rpc_requests = attachments : { 
II calls to map server 

incident_mgr .map_request to map_request_rpcl . client_end; 
map_server . request_portl to map_request_rpcl . server_end; 
resource_mgr .map_request to map_request_rpc2 . client_end; 
map_server . request_port2 to map_request_rpc2 . server_end; 



rpc_requests = attachments 



/ / incident info from incident_mgr 
resource_mgr . incident_inf o_request to 

incident_inf o_request_rpc . client_end; 
incident_mgr . incident_inf o_request to 

incident_inf o_request_rpc . server_end; 



/ / incident info from incident_mgr 
resource_mgr . incident_inf o_request to 

incident_inf o_request_rpc . client_end; 
incident_mgr . incident_inf o_request to 

incident_inf o_request_rpc . server_end; 



Figure 5: An architectural description in ACME and a slice of it. 



